Skip to content

QueryComposition arguments should ALWAYS be a getter#58

Merged
stackoverfloweth merged 1 commit intomainfrom
useQuery-always-getter
Oct 7, 2025
Merged

QueryComposition arguments should ALWAYS be a getter#58
stackoverfloweth merged 1 commit intomainfrom
useQuery-always-getter

Conversation

@stackoverfloweth
Copy link
Copy Markdown
Contributor

Consider the following example of useQuery in a Vue application

import { useQuery } from '@kitbag/query'

const { userId } = defineProps<{ userId: number }>()

const userQuery = useQuery(fetchUser, [userId])

It feels like this is right, but in this example the query is not reactive. If userId changes, the query won't know to execute fetchUser again with the updated argument. The solution of course is to use a getter for your arguments, but to avoid confusion we have decided instead to just always ask for a getter to supply the useQuery arguments

@stackoverfloweth stackoverfloweth self-assigned this Oct 6, 2025
const value = tag()

expectTypeOf(value).toMatchTypeOf<QueryTag>()
expectTypeOf(value).toExtend<QueryTag>()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because of the vitest deprecation yeah? What's the other option? Extends seems like the looser option.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct. Type hints for deprecated toMatchTypeOf suggested toExtend, didn't try too hard to find a better assertion 🤷

@stackoverfloweth stackoverfloweth merged commit 01efb4b into main Oct 7, 2025
2 checks passed
@stackoverfloweth stackoverfloweth deleted the useQuery-always-getter branch October 7, 2025 01:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants